โ RNS 1.4.2 released https://pypi.org/project/rns/
๐ฌค rns.recipes
top
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ Retichat-ios Testing Needed โ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
Started by jrl290 ยท 3mo ago
Page 4 of 5
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-31
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ jrl290 #31 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 2mo ago
Ghost_898 wrote:
> Thanks for verifying. But Iโm experiencing this โfreezeโ with only TCP connection
enabled too. It seems to stop receiving while on background entirely.
Yes, iOS doesn't allow persistent background connections. RFed is required for push
notifications to work, but there is a default RFed node used if nothing else is
configured. What do you have configured for RFed and LXMF Propagation addresses?
โ 0 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-32
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ Ghost_898 #32 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 2mo ago
jrl290 wrote:
> Ghost_898 wrote:
> > Thanks for verifying. But Iโm experiencing this โfreezeโ with only TCP connection
enabled too. It seems to stop receiving while on background entirely.
>
> Yes, iOS doesn't allow persistent background connections. RFed is required for
push notifications to work, but there is a default RFed node used if nothing else is
configured. What do you have configured for RFed and LXMF Propagation addresses?
I configured the identity hash of my meshchat running on docker, it does even
automatically recognize the propagation node which is enabled. But Retichat tells me โno
pathโ. Maybe thatโs the issue when RFed is responsible for notification. I tried
restarting meshchat but no luck.
โ 0 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-33
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ jrl290 #33 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 2mo ago
Ghost_898 wrote:
> I configured the identity hash of my meshchat running on docker, it does even
automatically recognize the propagation node which is enabled. But Retichat tells me โno
pathโ. Maybe thatโs the issue when RFed is responsible for notification. I tried
restarting meshchat but no luck.
Yes, if it says "no path" then that's at the root of the issue. And the Meshchat address
shouldn't be in that top field. Just clear it and it'll use the default RFed node
instead. You can have whatever you want in the bottom for the propagation node address,
but if you don't have anything then it'll use a default node for that as well
โ 0 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-34
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ Torlando #34 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 2mo ago
jrl290 wrote:
> KenAKAFrosty wrote:
> > Dang I've been a bit stuck. Did you use the LoRa interface or TCP?
>
> I reenabled the AutoInterface and put a minor amount of hardening for the privacy
filter code in (that's what best explains the double check and no receipt). Also the
QR code compatibility with Columba
>
> Just waiting for the App Store approval
One thing I observed with Columba is that I would get double checkmarks for sent
OPPORTUNISTIC messages (which means it got a delivery proof back) to Sideband, even
though Sideband didn't render the message. This turned out to be that Sideband has a
(user toggle-able) stamp cost 1 enforcement for incoming messages. The version of Columba
I was testing with at the time (1.0.x) had missed wiring up the stamper in the announce
handler, so it wasn't stamping messages when needed. I found it strange that Sideband
(probably LXMF under the hood) was sending delivery proofs even when the message was
dropped. I didn't dig into the code to find the exact line to confirm though, so I may
have been misinterpreting.
Anyway, just wanted to point this out - you might want to double check how the client
you're testing against handles its privacy filter, specifically whether it still sends a
delivery proof if the message is dropped or hidden from the user (and this might actually
be LXMF behavior, a layer down from whatever the app does, I haven't verified).
I could see arguments for either approach; sending a delivery proof leaves the sender
none the wiser that you have blocked incoming messages, while withholding the delivery
proof (while still announcing on an interval) indicates to the sender that you are either
never connected when they send a message, or that you have blocked them. On the flip
side, sending the delivery proof does tell the sender that you are connected/online, even
if you have blocked unknown senders. Same goes for accepting link requests.
โ 1 โ 0 โค 1
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-35
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ K8 #35 โ
โ 8e4525cda4482720 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 2mo ago
Torlando wrote:
> I found it strange that Sideband (probably LXMF under the hood) was sending delivery
proofs even when the message was dropped. I didn't dig into the code to find the
exact line to confirm though, so I may have been misinterpreting.
Currently delivery proofs are generated and sent directly from Transport during inbound
processing, while stamps are handled from the LXMF module, so as far as the
implementation that behavior makes sense. I imagine some of Markโs current work to bring
stamping within RNS itself would allow this behavior to change. Iโm also not sure if it
should change, but maybe thereโs a case for it being configurable.
โ 1 โ 0 โค 1
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-36
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ jrl290 #36 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 2mo ago
Torlando wrote:
> I could see arguments for either approach; sending a delivery proof leaves the sender
none the wiser that you have blocked incoming messages, while withholding the delivery
proof (while still announcing on an interval) indicates to the sender that you are either
never connected when they send a message, or that you have blocked them. On the flip
side, sending the delivery proof does tell the sender that you are connected/online, even
if you have blocked unknown senders. Same goes for accepting link requests.
I've looked at the code and what I want to happen. You know that I'm using custom rolled
Reticulum and LXMF rust code. So I'm inserting a hook into LXMF that short circuits the
proof mechanism as soon as the sender identity is decoded. If privacy is enabled and the
identity doesn't appear on the whitelist, no proof is run and no response is given
Some LXMF clients will be confused by this, I know. But I think it is important to
protect the device from spamming proof calls (on top of the decode call), especially
since the device broadcasts its address to the network.
โ 0 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-37
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ kujeger #37 โ
โ ab1f161e088beeb9 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 2mo ago
jrl290 wrote:
> kujeger wrote:
> > Hi, was just told of this and looks like we have a naming collision!
> > I've had https://codeberg.org/kujeger/retichat , a TUI lxmf chatting app,
for a while (it hasn't been very active lately as I've been waiting for
a suitable rust-based reticulum/lxmf implementation to appear, and I'm in the
process of porting it to rsReticulum/rsLXMF now).
> >
> > So we should probably figure something out around the naming.
>
> Ah balls, sorry about that. It must've slipped my view when doing basic name
checks.
>
> I don't see it as a substantially problematic collision though. The platforms
separate the target audiences pretty well. One specifically targeted to mainstream mobile
chat and the other for terminal users
>
> Is there something you'd like to see in particular? I could put a reference to
Retichat for TUI on my github description pages. If it means anything, I have no
intension of seeking any sort of trademark or anything like that
yeah no worries, great minds think alike and all that!
we can see how it turns out; your project seems to have more traction/users so I may end
up just changing the name of my client :)
โ 0 โ 0 โค 1
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-38
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ jrl290 #38 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 2mo ago
kujeger wrote:
> yeah no worries, great minds think alike and all that!
>
> we can see how it turns out; your project seems to have more traction/users so I may
end up just changing the name of my client :)
I wouldn't undersell your creation. TUI has a smaller audience inherently. Doesn't make
it unimportant
In my estimation there's no need to change the name, but of course that's up to you
โ 0 โ 0 โค 1
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-39
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ kujeger #39 โ
โ ab1f161e088beeb9 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 2mo ago
jrl290 wrote:
> kujeger wrote:
> > yeah no worries, great minds think alike and all that!
> >
> > we can see how it turns out; your project seems to have more traction/users so I
may end up just changing the name of my client :)
>
> I wouldn't undersell your creation. TUI has a smaller audience inherently.
Doesn't make it unimportant
>
> In my estimation there's no need to change the name, but of course that's up
to you
thanks, and yeah, I was just thinking that "fewer users is less disruption if there's a
name change" :D
โ 0 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-40
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ metrafonic #40 โ
โ 40e9896526f14a31 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 2mo ago
Awesome work! I love that you got RNodes working on iOS! I didnt think anyone had a
working implementation yet.
Could you allow setting the SF factor down to SF5? The dropdown currently only allows to
SF7. Many radios support it and i use that locally
โ 0 โ 0 โค 1
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
Page 4 of 5
โ INFO โ Identify to this node to post. How?
bottom